Process for access control to computer-controlled programs usable by several user units at the same time

ABSTRACT

A method for access control to computer-controlled programs, which can be used at the same time by a plurality of users. A user sends a request regarding a program to a unit for organizing a data flow. It is checked in this unit whether the user which sent the request, has originally started the program. When the user sending the request has started the program, the request is forwarded to the program. If not, an access control with respect to the request is carried out on the basis of an access control data bank. When it derives from the access control that the request is an allowed request, the request is forwarded to the program. When it derives from the access control that the request represents an unallowed request, the request is not forwarded to the program.

BACKGROUND OF THE INVENTION

Standard one-user applications (programs) can be introduced intocomputer-supported conferences by what is referred to as “sharing” ofcomputer-controlled programs. The persons participating in a conference,who can be at different locations, can thereby work in common with thestandard one-user application. All participants can view the outputs ofthe respective application used in common. Exactly one of theparticipating persons can make inputs to the application at any point intime.

This technical design for application distribution is the basis forinformation-oriented systems for supporting synchronous collaboration ofgeographically distributed persons.

There have previously been two different roles for the user in thetechnical conversion of the “sharing” of applications. It is thus amatter, first, of what is referred to as the “token holder”, thisindicating that person who has the right at the respective point in timeto make inputs for the application, and, second, what is referred to asthe “observer”, this indicating the other persons participating in theconference who can in fact observe the output of the application buthave no right at the respective point in time to make an input for theapplication.

The role of the “token holder” is time-dependent. It can change betweenthe participants during a conference; however, there is always exactlyone “token holder” at every point in time. This means that it is alwaysexactly one person at any point in time who has the right to make inputsfor the application. On the basis of this technical solution, each“token holder” works under the privileges and with the access rights ofthe owner of the application, i.e. with the rights of that user whostarted the application. The “token holder” can thus implement exactlythose operations with the application to which the owner of theapplication is authorized. The “token holder” can thus no longer bedistinguished from the actual owner of the application. The applicationcannot tell that various persons are working with it, nor can it tellwho is working with at a specific point in time. In a certain sense, therespective “token holder” becomes a personification of the applicationowner due to the existing technical constructs of the “sharing systems”.

This procedure harbors great security risks since the “token holder”thereby has access, for example, to the entire datafile system of theowner of the application when the application is, for example, a textprocessing program with corresponding functionality. In this case, the“token holder” could illegitimately erase, modify, read or copydatafiles without the owner of the application necessarily needing toknow about it.

Window systems are currently subdivided into two known categoriesdependent on the operations and operating mode that these window systemsemploy.

First, there are what are referred to as client-server window systemswith an open network interface (R. Scheifler et al., TheX-Window-System, ACM Transactions on Graphics, Vol. 5, No. 2, pp.79-109, April 1986); second, there are those without an open networkinterface. The latter are also known as monolithic graphics-based windowsystems GDWS (Microsoft Windows 3.1 Programmer's Reference, Volume 1:Overview, Microsoft Press, Redmond, ISBN 1-55615-453-4, 1992: R. Orfaliet al., Client/Server Programming with OS/2, Van Nostrand Reinhold, NewYork, ISBN 0-442-01833-9, 1993; Inside Macintosh, Volume VI, AddisonWesley, ISBN 0-201-57755-0,1991).

Further, expansions are also known that make the windows systems in a“sharing”-capable window system: (H. Abdel-Wahab et al., Issues,Problems and Solutions in Sharing X Clients on Multiple Displays,Internetworking: Research and Experience, Vol. 5, pp. 1-15, 1994;

D. Garfinkel et al., HP Shared X: A Tool for Real-Time Collaboration,Hewlett-Packard Journal, pp. 23-26, April 1994;

W. Minenko, Transparentes Application-Sharing unter X Window,Multimediale Telekooperation, Deutsches Forschungszentrum für KünstlicheIntelligenz (DFKI) GmbH, Saarbrücken, pp. 1-8, 1994;

J. Baldeschwieler et al., A Survey on X Protocol Multiplexors, ACMSIGCOMM, Computer Communication Review, Swiss Federal Institute ofTechnology, Computer Engineering and Networks Laboratory (TIK),ETH-Zentrum, Zürich, pp. 16-24, 1993,

U. Pech, Sichtlich beeindruckt, PC Professionell, pp. 71-88, October1995;

E. Chang et al., Group Coordination in Participant Systems, IEEE,Proceedings of the 24^(th) Annual Hawaii International Conference onSystem Sciences, Vol. 3, No. 4, Kauai, Hi., pp. 589-599, January 1991;

A. Nakajima, A Telepointing Tool for Distributed Meeting Systems, IEEEGlobal Telecommunications Conference and Exhibition, Vol. 1, No. 3, SanDiego, Calif., pp. 76-80, December 1990;

J. Patterson, The Implications of Window Sharing for a Virtual TerminalProtocol, IEEE International Conference on Communications, Vol. 1, No.4, Atlanta, Ga., pp. 66-70, April 1990;

G. Herter, Intel ProShare, Accounting Technology, Vol. 11, No. 1, pp.49-54, January 1995;

D. Riexinger et al., Integration of Existing Applications into aConference System, Proceedings of International Conference on MultimediaTransport and Teleservices, Vienna, pp. 346-355, November 1994).

Further, a security expansion is known for one-user applications usablein common by a plurality of users (G. Gahse, “Zugriffskontrolle inKonferenzsystemen”, IBM Deutschland Informationssysteme GmbH,Europäisches Zentrum für Netzwerkforschung, Heidelberg, 1995).

The previously known method for expanding the security of one-userapplications in conference systems describes an access control method,whereby a one-user application is to be used in common by a plurality ofusers sequences under specific “sharing privileges”. In this method, acommon, new, temporary identity is allocated to the users for the timespan of the collaboration. This common temporary identity has accessrights (“sharing”privileges) allocated to it, as a result whereof theoriginal rights can be set aside. For example, none of the conferenceparticipants can thus illegitimately access data of the local systemduring use of the application.

A critical disadvantage that can be seen in the known method is that theproposed access control mechanism does not take the various users intoconsideration in the allocation of requested resources, and, thus, nodistinction is possible between the “token holder” and the owner of theapplication.

A principal cause for security risks that still continue to exist giventhis method lies therein that a number of persons, for example thesystem administrator or other users as well that are recited in aspecific “authorization datafile”, can still set the rights of the otherusers for an application given this method. As a result of thisprocedure, users other than the actual owner of the application canstill “decide”, for example, over the datafile system of the owner ofthe application. This precondition of the trustworthiness of the userswho allocate the rights for applications represents a considerablesecurity risk.

SUMMARY OF THE INVENTION

It is a object of the invention to specify a method for access controlto computer-controlled programs that can be simultaneously used by aplurality of user units that avoids the security risks described above.

According to the present invention, a method is provided for accesscontrol to computer-controlled programs that can be simultaneously usedby a plurality of user units. A request is sent for a program from auser unit. The request for a program is received in a data floworganization unit. A check organization is performed in the data floworganization unit to see whether the user unit from which the requestwas sent had originally started the program. When the user unit sendingthe request had started the program, the request is forwarded to theprogram. When the user unit sending the request had not started theprogram, implementing an access control for the request on the basis ofan access control data bank. The request to the program is forwardedwhen the access control shows that the request represents an allowedrequest. The request to the program is not forwarded when the accesscontrol shows that the request represents an allowed request.

In this method, a distinction is explicitly made between the owner ofthe application, i.e. that user who started the application, therespective “token holder” and all other users. The owner of anapplication (program) produces an access control data bank in which,based on the identities of the other users as well as the type ofrequest that is sent by the users, he can determine as to his ownapplication whether the request of the respective user should be allowedor whether the request should be denied.

In the method, a received request for an application (program and set oflibrary routines) that can be simultaneously used by a plurality of userunits is received by a means for the organization of the data flow (whatare referred to as multiplexer components) and a check is subsequentlycarried out to see whether the request was sent from the user unit thathad originally started the program.

When this is the case and if the application owner has the input rightat the corresponding point in time, the request is forwarded directly tothe program.

Otherwise, an access control is implemented for the request on the basisof the access control data bank produced by the owner of theapplication. What the access control achieves is that only requestsexplicitly “authorized” by the owner are forwarded to the program.

The security of the “sharing” of applications in conference systems isconsiderably enhanced by this additional access control.

The method is simplified by the development of the method of theinvention in that, before the check whether the user unit had originallystarted the program, a check is carried out to see whether the user unitthat sent the request had a processing right at all, i.e. whether thisuser unit was a “token holder”. When this was not the case at the pointin time of the transmission, the request is not even supplied to thefurther method steps of the invention.

The access control is thus avoided for requests that were sent by usersthat were not a “token holder” at the point in time the respectiverequest was sent, as a result whereof considerable savings incalculating time are achieved since the access control no longer has tobe carried out for all requests received by the means for organizing thedata flow (multiplexer unit).

As a result of a further development of the method according to theinvention, the security of the method is enhanced further by anauthentification of the user unit that has sent the request and/or ofthe request itself.

The invention is explained in greater detail below on the basis ofdrawings that shows two exemplary embodiments of the inventive method.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic arrangement of resources that employ a windowsystem of a first exemplary embodiment that is expandable to a windowsystem in which applications can be simultaneously used by a pluralityof users;

FIG. 2 is a schematic arrangement of an expansion of the resourcesdescribed in FIG. 1, as a result of which the simultaneous use of anapplication by a plurality of users is possible;

FIG. 3 is a flowchart in which individual method steps of the inventivemethod of the invention are shown;

FIG. 4 is a flowchart in which a development by means of anauthentification of the request and/or of the sender of the request isimplemented;

FIG. 5 is a flowchart in which a development of the method is described,whereby a check is carried out at the beginning of the method as towhether the user unit sending the request has a processing right for theapplication at the time of the transmission;

FIG. 6 is a structogram in which the information that should be at leastcontained in an access control data bank is shown;

FIG. 7 is an arrangement in which the necessary security expansion ofthe arrangement described in FIG. 2 is represented by an access controldata bank; and

FIG. 8 is a schematic arrangement of resources that employ a monolithic,graphics-based window system of a second exemplary embodiment that isexpandable to a monolithic, graphics-based window system in whichapplications can be simultaneously used by a plurality of users.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

For explanation of a first exemplary embodiment, FIG. 1 shows anarrangement in which individual components (resources) are describedthat use a known windows system described in R. Scheifler et al., The XWindow System, ATM Transactions on Graphics, Vol. 5, No. 2, pp. 79-109,April 1986.

This arrangement comprises at least the following components:

a user unit, referred to below as a server XS, which in turn comprisesthe following components:

At least one driver unit DD that enables a coupling between furtherperiphery components with a client XC described later,

a picture screen unit BS,

a keyboard TA,

a mouse MA,

the client XC, which comprises at least the following components:

a set of library routines XL, and an application ANW.

The picture screen unit BS, the keyboard TA, the mouse MA as well as,potentially existing other periphery units form the above-describedperiphery components that are coupled to the client XC via thecorresponding driver units DD.

The set of library routines XL of the client XC forms the interfacebetween the known, above-described window system and the applicationANW.

Together, the library routines XL as well as the application ANW form aprogram P.

Even though only respectively one application ANW or, respectively, oneprogram P is described in this exemplary embodiment, a plurality ofapplications ANW and, thus, a plurality of clients XC can, of course, bemade available on a computer unit executing these applications ANW.

This arrangement shown in FIG. 1 is thus only a very simple, basicexample of the execution of the communication of a client XC with theserver XS as implemented under the known window system.

A request A is sent from the server XS to the client XC, as a resultwhereof actions, for example in the application ANW, are initiated inthe client XC. This request can, for example, represent an input on thekeyboard that is “translated” into the request A by the driver units DDand sent to the client XC.

The application ANW, for example a text processing program or acalculation program as well, a drafting program and similar programs,can now accept the input and, for example, incorporate it into the textdatafile as a new letter.

So that the modification in the text datafile can also be displayed onthe picture screen BS, a display request (by way of example in thiscase) is sent in an answer B to the picture screen unit BS to implementa modification in the picture screen display.

FIG. 2 shows an arrangement that, compared to the arrangement describedin FIG. 1, is expanded by a means for the organization of the data flow,which is referred to below as a multiplexer component ASC, so that aconference system is enabled on the basis of the window system describedabove.

A number of different realizations of the multiplexer component ASC areknown. These are described, for example, in (D. Garfinkel et al., HPShared X: A Tool for Real-Time Collaboration, Hewlett-Packard Journal,pp. 23-26, April 1994; W. Minenko, Transparentes Application-Sharingunter X Window, Multimediale Telekooperation, DeutschesForschungszentrum für Künstliche Intelligenz (DFKI) GmbH, Saarbrücken,pp. 1-8,1994.

An investigation of different realizations of the multiplexer componentASC is described in (J. Baldeschwieler et al., A Survey on X ProtocolMultiplexors, ACM SIGCOMM, Computer Communication Review, Swiss FederalInstitute of Technology, Computer Engineering and Networks Laboratory(TIK), ETH-Zentrum, Zürich, pp. 16-24, 1993.

The multiplexer component ASC now makes it possible that a plurality ofservers XSi communicate via the multiplexer component ASC with theclient XC and can thus respectively access the program P. An index ithereby respectively unambiguously identifies every server XSi and is anarbitrary natural number between 1 and n, whereby the number n indicatesthe plurality of servers XSi that are coupled to the client via themultiplexer component ASC.

The multiplexer component ASC should comprise at least the followingproperties:

The multiplexer component ASC is connected between the client XC and theservers XSi.

Relative to the client XC, the multiplexer component assumes thefunctionality of a single server XS in order to thus preserve thefunctionality of the arrangement according to FIG. 1.

Relative to the n servers XSi, the multiplexer component ASC assumes thefunctionality of the client XC, as a result of which n “logical clients”are modelled by the multiplexer component ASC.

A conference inquiry Ai is thus respectively sent to the multiplexercomponent ASC from a server XSi. In the multiplexer component ASC, therespective conference inquiry Ai is converted into the inquiry A that issent to the client XC.

By contrast to the arrangement that was described in FIG. 1, the displayrequest B of the client XC is sent to the multiplexer component ASC,where it is then converted into a conference display request Bi and issent to the respective server XSi that sent the conference inquiry Ai.

Dependent on the type of conference display request Bi, however, it canalso necessary that the display request B is distributed to every serverXSi. This is necessary, for example, when the display request B isformed of in a request to the picture screen unit BS (see FIG. 1) since,of course, a modification of the picture screen content must be visibleon every server XSi.

The multiplexer component ASC thus assumes the functionality of amultiplexer and demultiplexer, i.e. the organization of the data flow.

The display request B of the client XC to the coupled servers XSi isthus multiplexed in the multiplexer component ASC, whereby copies of thedisplay request B are sent to the individual servers XSi.

Changes in the individual conference display requests Bi are therebyimplemented according to the different resources of the servers XSi, forexample given different color displays at the servers XSi, whendifferent types of picture screen units (see FIG. 1) BS are employed atthe server XSi or the like.

Conference requests Ai sent by the servers XSi are collected in themultiplexer component ASC and potentially unallowed conference requestsAi are filtered out.

 The allowed conference requests Ai are forwarded to the client XC asthough these conference requests Ai came directly from a single serverXS (see FIG. 1) and not, as is in fact the case, from a plurality ofservers XSi.

 FIG. 3 shows individual method steps of the inventive method.

All component references are from FIG. 2.

In a first step 1, a conference request Ai is sent from an arbitraryserver XSi to the multiplexer component ASC.

The conference request Ai is received 2 by the multiplexer componentASC.

After reception of the conference request Ai, a check is made in afurther step 3 to see whether the server XSi that sent the conferencerequest Ai originally started the program P to which the conferencerequest Ai relates.

This corresponds to the check whether the sender of the conferencerequest Ai is the owner of the application ANW.

When the server XSi sending the conference request Ai originally startedthe program P and when it has the input right at the corresponding pointin time, the multiplexer component ASC forwards (step 4 ) the conferencerequest Ai directly to the client XC and, thus, to the program P and theapplication ANW.

This occurs because the owner of the application ANW has completecontrol of his application ANW in the framework of this invention. Forthis case, thus, it is also not necessary to implement a further accesscontrol for conference requests Ai that were sent by the owner of theapplication ANW.

When, however, the conference request Ai is sent by a server XSi that isnot the owner of the application ANW, an additional access control isimplemented (step 5) for the conference request Ai on the basis of anaccess control data bank ZDK(see FIG. 6 and 7). The access controldistinguishes the conference request Ai into allowed conference requestsAi and unallowed conference requests Ai.

In a further step 6, the result of the access control (step 5)implemented above is reviewed. When the application owner classified theconference request Ai as an unallowed conference request Ai, theconference request Ai is not forwarded to the client XC and, thus, isalso not forwarded to the application ANW but is discarded (step 7).

When, however, the conference request Ai was classified by theapplication owner as an allowed conference request Ai, this conferencerequest Ai is forwarded (step 8) to the client XC and, thus, to theapplication ANW.

As a result of this procedure, a distinction is made not only, aspreviously, between the person who has a processing right at the pointin time of transmission of the conference request Ai, i.e. is what isreferred to as the “token holder”, and the further users, what arereferred to as “observers”.

A further distinction is added by the inventive method, namely thedistinction whether or not the server XSi that sent the conferencerequest Ai is also the owner of the application ANW, i.e. whether or notthe application ANW had been originally started by the correspondingserver XSi.

Given a suitable classification of allowed conference requests Ai by theapplication owner in the access control data bank ZDK (see FIG. 6 and7), this additional distinction prevents unauthorized third parties fromaccessing resources of the owner of the application ANW.

As a result of the inventive method, only the owner of the applicationANW is now authorized to completely access his own resources.

Moreover, the owner of the application ANW has the sole right toconstruct the access control data bank ZDK (see FIG. 6 and 7) and, thus,is the only one having the possibility of quite specifically granting ordenying specific rights for the conference participants with whom heuses the application ANW he started in common, i.e. all other serversXSi.

The security risk that the method described in G. Gahse,“Zugriffskontrolle in Konferenzsystemen”, IBM DeutschlandInformationssysteme GmbH, Europäisches Zentrum für Netzwerkforschung,Heidelberg, 1995 comprises and that was described above is thus alsoavoided, since no user units other than the owner of the application ANWhimself can grant access rights to the application ANW and also have no“omnipotent” access rights to the application without the consent of theowner of the application ANW.

The access control data bank is thus exclusively set up and controlledby the owner of the application ANW, i.e. proceeding from that serverXSi from which the application ANW has been originally started.

The access control data bank ZDK should comprise at least the followinginformation in order to be able to efficiently implement the accesscontrol for each conference request Ai (see FIG. 6):

A specification of the client XC (see FIG. 2) to whom the entry in theaccess control data bank ZDK refers, for example by specification of anInternet protocol address (IP) and, additionally, of the correspondingaddress of the port;

a specification AXSi of the server XSi (see FIG. 2) to which the entryin the access control data bank ZDK refers, for example by specifyingthe picture screen address of the respective server XSi (see FIG. 2);

a specification of the respective type AAT of the conference request Aito which the entry in the access control data bank ZDK refers, forexample XCreate, XRequest, etc., for the first exemplary embodimentgiven the above-described window system;

further parameters WP the further parameters WP can, for example,comprise an allowed value range for the respective conference requesttype.

The way in which the access control data bank is allowed to beconstructed and modified can be variously realized.

For example, it is provided that the owner of the application ANW (seeFIG. 2) constructs the access control data bank as text datafile withthe assistance of a text editor.

Further, it is also provided to employ a picture screen mask forconstructing the access control data bank ZDK, this intuitively enablingand, thus, facilitating the input for producing the access control databank ZDK for the owner of the application ANW.

It is also provided to define templates for predetermined conferenceparticipants. The templates are access control data banks that werepredefined for specific security scenarios, for example for specificapplications and for specific conference participants, and, easilycallable for the respectively started application ANW (see FIG. 2), canbe incorporated as access control data bank ZDK by the owner of theapplication.

Additional measures for the authentification of the messages that servefor the definition, i.e. the production of the access control data bankZDK or, further, for the modification of the data in the access controldata bank ZDK are provided in a development of the method in order toprevent unauthorized third parties obtaining access to the accesscontrol data bank ZDK itself.

Cryptographic methods for authentification are familiar to a personskilled in the art, for example asymmetrical cryptographic methods withwhich a digital signature and, thus, an authentification of the senderof the respective message is possible or, further, the employment of aone-way function with which a hash value is formed at least over a partof the conference request Ai. (see FIG. 2).

In a development of the method, which is shown in FIG. 4 (but where allcomponent references are to FIG. 2), an initialization of theauthentification described below is implemented (step 41) before thebeginning of the method.

This occurs, for example, with the following procedure.

Given the assumption that the multiplexer component ASC has anapplication certificate and the user units, i.e. the servers XSi,respectively have a user certificate that are respectively unambiguouslyallocated to the user units, the multiplexer component ASC thengenerates a first random number.

After a transport connection has been set up between the multiplexercomponent ASC and the respective server XSi, the multiplexer componentASC sends a first negotiation message to the user unit, this comprisingat least the following components:

the program certificate,

the first random number,

a first proposal for a cryptographic method to be subsequently employed,and

a digital signature that is formed at least over the first random numberas well as the first proposal.

The first negotiation message is received by the respective user unit,i.e. the server XSi.

The user unit XSi checks the program certificate for correctness.

Further, the digital signature is checked.

When the check of the program certificate and of the digital signaturesupplies a positive result, a further check is carried out in the userunit XSi to see whether the proposed cryptographic algorithms that wereproposed in the first negotiation message can be subsequently employedfor the authentification and safeguarding of the transmission.

When the user unit XSi cannot support the proposed cryptographicalgorithms, the user unit, i.e. the server XSi, forms a second proposalin a second proposal message and sends it to the multiplexer componentASC. The second proposal comprises cryptographic methods that the userunit XSi supports. These are now proposed to the multiplexer componentASC as cryptographic methods to be employed in the further method forthis logical connection between the multiplexer component and the userunit XSi.

The second proposal message comprises at least the following components:

the user certificate of the respective server XSi,

a second random number that was generated by the user unit XSi itself,

the second proposal,

a digital signature that is respectively formed at least over the firstrandom number, the second random number as well as the second proposal.

The second proposal message is sent to the multiplexer component ASC.

When the cryptographic algorithms indicated in the first proposal aresupported by the user unit XSi, the user unit XSi forms anacknowledgment message and sends it to the multiplexer component ASC.

The acknowledgment message comprises at least the following components:

the user certificate

the second random number,

a positive acknowledgment, and

a digital signature that is respectively formed at least over the firstrandom number, the second random number and the positive acknowledgment.

The acknowledgment message is sent to the multiplexer component ASC.

The negotiation message or the acknowledgment message is received by themultiplexer component ASC and a check is performed in the multiplexercomponent ASC to see whether the user certificate as well as the digitalsignature are correct.

When the check supplies a positive result and the received message wasthe acknowledgment message, further, the multiplexer component ASCgenerates a first session key taking the declared cryptographicalgorithms into consideration for a following useful data transmissionphase.

A first session key message that comprises at least the followingcomponents is formed from the first session key and sent to the userunit XSi:

the first session key encoded with the public key of the server XSi,

a specification of the cryptographic methods to be employed,

a digital signature formed at least over the first random number, thesecond random number, the first session key, as well as thespecification of the cryptographic methods to be employed.

When the second negotiation message was received by the multiplexercomponent ASC and the check of the user certificate and of the digitalsignature or of the hash value of the second negotiation message hassupplied a positive result, a check is carried out in the multiplexercomponent ASC to see whether the cryptographic algorithms proposed inthe second negotiation message for the implementation of the furthercryptographic methods are supported by the multiplexer component ASC.

When the proposed cryptographic methods are supported by the multiplexercomponent ASC, a first session key is generated taking the declaredcryptographic algorithms for the following useful data transmissionphase into consideration.

As was described above, further, a first session key message is sent tothe multiplexer component ASC upon employment of the first session key.

This above-described procedure for the “negotiation” of thecryptographic methods to be employed is repeated until both the userunit XSi as well as the multiplexer component ASC accept the mostrecently proposed cryptographic method.

The first session key is determined in the user unit XSi upon employmentof a private key of the user unit XSi. Further, the digital signature ofthe first session key message is checked.

When the check of the digital signature supplied a positive result, asecond session key message is also formed upon employment of a secondsession key that is formed by the user unit XSi.

The second session key message comprises at least the followingcomponents:

the second session key encrypted with a public program key of themultiplexer component ASC,

a digital signature formed at least over the first random number, thesecond random number, the second session key or a hash value formed overthe same components.

The multiplexer component ASC receives the second session key messageand determines the second session key. The digital signature or the hashvalue of the second session key message is checked.

When the check of the digital signature supplied a positive result, thesession keys that have been exchanged are employed in the followinguseful data transmission phase for the encryption of the useful data.Each participating entity thereby employs the session key that it itselfgenerated for the transmission of useful data, whereas the receivedsession key is employed exclusively for the reception of useful data.

Further cryptographic methods for the key exchange or, respectively, forthe formation of the session key for the useful data encryption can beutilized without limitation in the framework of the inventive method.

After the initialization phase for the authentification (step 41) hasbeen concluded, an authentification of the conference request Ai and/orof the user unit XSi sending the conference request Ai is implemented(step 42) in the multiplexer component ASC in the useful datatransmission phase respectively after reception of the respectiveconference request Ai.

In a further step 43, a check is carried out to see whether theauthentification supplied a positive result. When this is the case, theconference request Ai is supplied (further steps L) to the furthermethod describe above.

When, however, the authentification (steps 43) yielded a negativeresult, the conference request Ai is discarded and, thus, is notforwarded (steps 44) to the client XC.

A development of the method is also comprised in checking (step 2) withthe multiplexer component ASC after reception of the conference requestAi to see whether the user unit XSi that sent the conference request Aihad (steps 51) a processing right at the respective point in time of thetransmission (see FIG. 5).

This corresponds to the question as to whether the user unit XSi was“token holder” of the application ANW at the point in time of thetransmission of the conference request Ai.

When this is the case, the conference request Ai is subjected (furthersteps L) to the further method steps of the inventive method. When,however, this is not the case, the conference request Ai is notforwarded and is thus discarded (steps 52).

This development exhibits the advantage that a conference request Aithat is not allowed anyway since it was sent from a user unit XSi thatdid not possess the processing right at all at the time is subjected tothe entire method. Superfluous access controls are thus avoided.

The necessary expansion of the arrangement described in FIG. 2 so thatthe arrangement can implement that method described above is shown inFIG. 7. This expansion is comprised therein that an additional accesscontrol data bank ZDK is provided in the multiplexer component ASC.

Further, of course, the provided checks that were described above mustbe implemented.

In a second exemplary embodiment, the method is described for computerunits that employ monolithic, graphics-based window systems thatcomprise no open communication interface between the application ANW andthe window system (see FIG. 8).

Examples of such monolithic graphics-based window systems are known andwere cited above.

Given monolithic graphics-based window systems, the window protocol mustlikewise be “broken up” between the application ANW and the userinterface for the distribution of a one-user application. The procedureis thereby fundamentally analogous to that already described.

The possible points for the intervention into the window protocol aredescribed below.

The structure of this monolithic graphics-based window system GDWS isshown in FIG. 8.

Monolithic graphics based windows systems GDWS comprise at least thefollowing components:

the picture screen BS,

the keyboard TA,

the mouse MA,

graphics card driver programs GDD,

graphics library routines BCL,

window library routines WL with an input handler IL,

the application ANW.

In this exemplary embodiment, the application ANW runs in the sameenvironment as the graphics-based window system GDWS, and both employ aset of function calls in a common memory in order to communicate withone another.

Since graphics-based window systems GDWS comprise no open communicationinterface, the structure shown in FIG. 8 must be intervened in forapplications ANW that are to be simultaneously used by a plurality ofusers.

The expansions can be undertaken at various locations of the respectivegraphics-based window system GDWS, for example at a first programminginterface between the window library routines WL and the applicationANW, at a second programming interface between the graphics libraryroutines BCL and the window library routines WL or at the graphics carddriver programs GDD.

These modifications are only possible if the window library routines WL,the graphics library routines BCL or the graphics card driver programsGDD are not permanently bound to the application ANW but dynamically.These types of programs are referred to as dynamic link library (DLL).

The necessary modifications are known.

The inventive method itself is also implemented as described above giventhese monolithic, graphics-based window systems GDWS.

Although various minor changes and modifications might be proposed bythose skilled in the art, it will be understood that my wish is toinclude within the claims of the patent warranted hereon all suchchanges and modifications as reasonably come within my contribution tothe art.

What is claimed is:
 1. A method for access control tocomputer-controlled programs that can be simultaneously used by aplurality of user units, comprising the steps of: sending a request fora program from a user unit; receiving the request for the program in adata flow organization unit; performing a check organization in the dataflow organization unit to see whether the user unit from which therequest was sent had originally started the program; when the user unitsending the request had started the program, forwarding the request tothe program; when the user unit sending the request had not started theprogram, implementing an access control for the request on the basis ofan access control data bank; forwarding the request to the program whenthe access control shows that the request represents an allowed request;and not forwarding the request to the program when the access controlshows that the request represents an unallowed request.
 2. The methodaccording to claim 1, wherein before the check whether the user unit hadoriginally started the program, performing a check in the organizationunit to see whether the user unit possesses a processing right at thetime of transmission of the request; and not forwarding the request tothe program when the user unit had no processing right.
 3. The methodaccording to claim 1, wherein an authentification of the user unit thatsent the request or of the request is implemented at a beginning of themethod.
 4. The method according to claim 3, wherein an initializationphase for the authentification is implemented given a connection setupbetween a user unit and the program.
 5. Method according to claim 1whereby the access control data bank comprises at least the followinginformation: a specification of the client to which the entry in theaccess control data bank refers; a specification of the window to whichthe entry in the access control data bank refers; the user unit; aspecification of a request type whose more detailed properties arespecified in further parameters; and further parameters that the requestmust comprise in order to be accepted as an allowed request.
 6. A methodfor access control to computer-controlled programs that can besimultaneously used by a plurality of user units, comprising the stepsof: sending a request for a program from a user unit; receiving therequest for the program in a data flow organization unit andauthenticating the user unit that sent the request; implementing aninitialization phase for the authentification given a connection setupbetween the user unit and the program; providing the organization unitas a multiplexer component; in the initialization phase, where the userunit has a user certificate and the multiplexer component has a programcertificate, performing the following steps: generating a first randomnumber by the multiplexer component; with the multiplexer component,sending a first negotiation message to the user unit, said negotiationmessage comprising at least the following components a programcertificate, a first random number, a first proposal, and a digitalsignature that is formed at least over the first random number and thefirst proposal; receiving the first negotiation message by the userunit; checking the program certificate by the user unit; checking thedigital signature by the user unit; when the check of the programcertificate and of the digital signature supplies a positive result,with the user unit checking whether proposed cryptographic algorithmscan be subsequently employed; when the cryptographic algorithms are notsupported by the user unit with the user unit forming a second proposalin a second proposal message and sending the second proposal to themultiplexer component, said second proposal message comprising at leastthe following components: the user certificate, a second random numberthat is generated by the user unit, a digital signature that is formedat least over the first random number, the second random number and thefurther proposal; when the cryptographic algorithms are supported,forming with the user unit an acknowledgment message and sending it tothe multiplexer component, said acknowledgment message comprising atleast the following components a user certificate, a second randomnumber that is generated by the user unit, a positive acknowledgment,and a digital signature that is formed at least over the first randomnumber, the second random number and the positive acknowledgment;receiving the second negotiation message or the acknowledgment messageby the multiplexer component; checking with the multiplexer componentthe user certificate; checking with the multiplexer component thedigital signature; when the check of the user certificate and of thedigital signature supplies a positive result and the acknowledgmentmessage was received, generating with the multiplexer component a firstsession key taking the declared cryptographic algorithms for a followinguseful data transmission phase into consideration; when the check of theuser certificate and of the digital signature supplies a positive resultand the further negotiation message was received, checking with themultiplexer component whether the proposed cryptographic algorithms canbe subsequently employed; when the proposed cryptographic algorithms canbe subsequently employed, generating with the multiplexer component afirst session key taking the declared cryptographic algorithms for afollowing useful data transmission phase into consideration; sendingwith the multiplexer component a first session key message to the userunit, said first session key message comprising at least the followingcomponents: the first session key encrypted with a public key of theuser unit, and a digital signature formed at least over the first randomnumber, the second random number, and the first session key; determiningwith the user unit the first session key upon employment of a privateuser key; checking with the user unit the digital signature; sendingwith the user unit a second session key message to the program, saidsecond session key message comprising at least the following components:the second session key encrypted with a public key of the multiplexercomponent, a digital signature or hash value formed at least over thefirst random number, the second random number, and the second sessionkey; receiving the second session key message with the multiplexercomponent; checking the digital signature or the hash value with themultiplexer component; and beginning the useful data transmission phasewhen the check supplies a positive result, whereby each entity employsthe session key that it itself generated for the sending of data, andwhereby the respectively received session key of the collaboratingentity is employed exclusively for the reception of transmittedmessages; performing a check organization in the data flow organizationunit to see whether the user unit from which the request was sent hadoriginally started the program; when the user unit sending the requesthad started the program, forwarding the request to the program; when theuser unit sending the request had not started the program, implementingan access control for the request on the basis of an access control databank; forwarding the request to the program when the access controlshows that the request represents an allowed request; and not forwardingthe request to the program when the access control shows that therequest represents an unallowed request.